Fix package structure and use shared Prettier, ESLint, TypeScript configs - #13
Conversation
This reverts commit 68c3b62.
| @@ -3,17 +3,12 @@ | |||
| "compilerOptions": { | |||
| "module": "es2020", | |||
| "outDir": "./dist/esm", | |||
There was a problem hiding this comment.
In the old we had the output on ./dist for the esm module.
That allows you to import import { Query } from '@aboutbits/react-pagination/dist/engine'.
I'm not sure if the current version would work because you tell them to always look into /dist/esm
Moreover I find it a bit strange that you have esm in the import, because it looks like the programmer has to explicitly select the component with esm module resolution.
There was a problem hiding this comment.
I chose this output directory so that the user of the library knows what is being used. Because we have no entry point, the user must choose. I think that naming the directories dist/esm and dist/cjs is more clear than naming them dist and dist/cjs or dist/esm and dist.
Do you think it is better to default to esm or cjs? If yes, to which one would you default?
There was a problem hiding this comment.
I see it more from the user perspective and there you don't care about the module system. You just want to import the component. Right now a user would have to decide. Should I take esm or cjs?
I would therefore choose a default. I think we use esm in the other packages.
There was a problem hiding this comment.
In the old package @aboutbits/react-pagination and the package @aboutbits/react-toolbox we use cjs as the default. What default should I take?
There was a problem hiding this comment.
I see that a build of Next.js fails when importing the esm version. So should we default to cjs?
There was a problem hiding this comment.
Thanks for checking. Go ahead with `cjs.
Because we intend to support Node.js versions
<= 12, we have to renounce on the multiple entry points. Otherwise we cannot use the package.We now also use the shared configs for Prettier, ESLint and TypeScript.